なんとなく「Fargate for EKS」が分かった気になる？～いろいろなギモンを調べてみた～ #reinvent

「Fargate for EKS」について、公式ドキュメントベースでの情報を中心に、概要をご紹介します。

AWS re:Invent 2019

#Kubernetes

#AWS Fargate

#Amazon EKS

#AWS

青柳英明

2019.12.04

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

みなさん、こんにちは！
AWS事業本部の青柳＠福岡オフィスです。

re:Invent 2019、12/3 (現地時間) に行われた Andy Jassy Keynoteで、コンテナ界隈 (？) には待望の「Fargate for EKS」が発表されました。

私も早速「やってみた」ブログを公開しましたが、ごくシンプルなサンプルを動かしてみただけですので、イマイチ「ピン」と来ない方がいらっしゃるかもしれません。
(と言うか、私もピンと来ていないところがあります)

また、「今までのEKSとどう違うの？」とか「何ができて何ができないの？」など、いろいろな疑問も出てくると思います。
(はい、私もいろいろ疑問が湧いてきました)

そこで、まずは、公開されているドキュメントベースで「Fargate for EKSとは何ぞや？」について調べてみましたので、みなさんにご紹介したいと思います。

「Fargate for EKS」とは

「Fargate for EKS」って何？

サーバーレスコンテナ実行基盤である「Fargate」はこれまでECS (Elastic Container Service) のみで使うことができましたが、このFargateをEKS (Elastic Kubernetes Service) でも使えるようにしたものです。

ECSにおいて、Fargateの登場によりコンテナインスタンス (EC2) の管理から解放されたように、「Fargate for EKS」でも同様にEC2ワーカーノードの管理から解放されることが期待されます。

Fargateと従来のEC2ワーカーノードとの関係は？

「Fargate for EKS」におけるFargateは、従来のEC2ワーカーノードと同居することもできますし、EC2ワーカーノードを完全に排除した「Fargateのみ」の構成にすることも可能です。

ECSであれば、EC2コンテナインスタンスが無くFargateのみの構成にすることは当然可能ですので「そんなの当たり前じゃん」と思われるかもしれませんが、ことEKSにおいては「Fargateのみの構成が可能」というのは画期的なことかもしれません。

と言うのも、「Fargate for EKS」登場以前にKubernetesにおいてサーバレスコンテナ統合を実現する手段であった「Virtual Kubelet」では、ワーカーノードを完全に排除することができなかったからです。
(Virtual Kubeletを制御するモジュールをサーバーレスコンテナ上で実行することはできず、ワーカーノード上で実行する必要があるため)

ともかく、ECSにおけるFargateの位置付けと同様の使い勝手でEKSでもFargateを使うことができるというのは、ECSに慣れているユーザーやECSからEKSへの乗り換えを考えているユーザーには嬉しいことなのではないでしょうか。

「Fargate for EKS」を使うにあたって

前提条件は？

Kubernetesのバージョンが 1.14 以上であること
eksプラットフォームのバージョンが eks.5 以上であること

新規にEKSクラスターを作成する場合には気にする必要がありませんが、既存のEKSクラスターをFargate対応にしようとする場合は、上記のバージョンを確認しましょう。

加えて、AWS CLIやeksctlを使う場合には、各コマンドツールのバージョンが以下の通りである必要があります。

AWS CLI： 1.16.296 以降であること
eksctl： 0.11.0 以降であること (※ 2019/12/4時点ではRC版である 0.11.0 rc0 のみが公開されています)

どうやって使い始めればいいの？

「やってみた」ブログのエントリー「Amazon Fargate for Amazon EKSを試してみた」を参考にして頂ければと思いますが、大まかには以下の流れです。

1. EKSクラスター (＝コントロールプレーン) を作成する
2. 「Fargateプロファイル」を作成する
3. kubectlコマンドを使ってKubernetes上でPod (Deployment/ReplicaSetなど) を起動する
4. Pod起動の要求に応じて自動的にFargateが起動して、Fargate上でPodが実行される

ポイントとなるのは主に「2」の工程です。
詳しくは次のトピックで説明します。

「Fargateプロファイル」って何？どうやって作るの？

ザックリと言うと「EKSでFargateを利用するための設定情報」です。

大きく分けて以下の2つの設定があります。

(1) Fargateを利用するための権限とネットワークの設定
(2) PodをFargate上で実行させる際の振り分け条件の設定

(1)については「Pod実行IAMロール」と「サブネット」の指定があります。

Pod実行IAMロールは、ECSでの「タスク実行ロール」と同じような概念です。
基本的な作成方法はPod Execution Roleを参照してください。

サブネットについては、「プライベートサブネットのみ指定可能」という点に注意をしてください。

(2)については「Pod selector」という形で設定を行います。

Pod selectorは、次の2通りの指定方法を取ります。

KubernetesのNamespaceを指定する
KubernetesのNamespaceおよびLabelを指定する

前者であれば、「指定したNamespaceに属するPodは全てFargate上での実行対象とする」となります。
後者の場合は、「指定したNamespaceに属するPodのうち、Labelに指定したキー・値が設定されているもののみをFargate上での実行対象とする」です。

Pod selectorの指定に合致するPodはFargate上で実行され、合致しないPodはFargate上で実行されません。(つまり既存のEC2ワーカーノード上で実行されます)

※ なお、条件に合致するPod selectorが複数存在する場合は、ランダムにいずれか一つが選択される仕様です。
意図的にそのような状況にすることは考え難いですが、予期しない振り分け動作をした場合のトラブルシュートの際には覚えておくと良いかもしれません。

「Fargate for EKS」を使う上での制約事項はあるの？

GPUコンピューティングリソースは利用できない

FargateにはGPUサポートは無いため、利用できません。
「Amazon EKS最適化AMI (GPU対応あり)」を使ったEC2ワーカーノードを構成する必要があります。

Kubernetesの「DaemonSet」リソースは非対応

「DaemonSet」とは、ワーカーノードのホスト1台につき1つのPodを常駐させるスケジュール方式ですので、ホストが存在しないFargateでは対応していません。
DaemonSetのユースケースとしては「ログ収集/転送」や「モニタリング」などが代表的ですが、そのような目的の場合には「サイドカーコンテナ」を用います。

Kubernetesの「HostPort」「HostNetwork」は非対応

これらはいずれも、Podがワーカーノードのホストネットワークに直接アタッチする形式ですので、Fargateでは対応していません。

Fargate (およびPod) にパブリックIPアドレスを割り当てることはできない

つまり、外部 (インターネット) からの直接着信を受け付けるPodは作成できないということになります。

ただし、そもそものEKSの設計指針としては、Pod等のワークロードをパブリックサブネットに配置することは推奨されていません。
ワークロードはプライベートサブネットに配置して、LoadBalancerやIngressを使用してパブリックからプライベートに着信させることが推奨されています。

LoadBalancerのCLB/NLBは非対応

EKSではKubernetesの「LoadBalancer」リソースを使用してPodの負荷分散を行う場合にCLB (Classic Load Balancer) やNLB (Network Load Balancer) が利用されますが、「Fargate for EKS」ではこれらに対応していません。

では、どうやって負荷分散、ひいては (前述の) インターネットからの通信要求をプライベートサブネット上のFargateに着信させるかと言うと、「Ingress」(Ingress Controller) を使用します。
IngressはALB (Application Load Balancer) を使ったL7レベルの負荷分散を行うことが可能です。